iT邦幫忙

2021 iThome 鐵人賽

DAY 6
1
IT管理

初階主管求生指南系列 第 6

[Day06] 團隊系統設計 - 張力分析

  • 分享至 

  • xImage
  •  

某次參加站立會議,某位 PM 情緒激動的說:「我後天要跟客戶回報進度了,但 A 同事這週請假三天,明天才回來,他手上的工作都沒有進展,我後天是要開天窗嗎?」此時團隊的眼神全向我掃來,因為我是 A 同事的直屬主管,此時,我空降這個團隊剛滿三個月。

我之前的文章有提過,空降初期,以觀察與欣賞為主;這個事件暗示了「禪機」已到,我嗅到了改革的機會。在這個事件中,PM 身上明顯有張力,張力會試圖被舒緩,這是一個簡單的張力-舒緩系統:
https://ithelp.ithome.com.tw/upload/images/20210921/20129624DnPnc39S6h.png

最直觀的解法,就是趕快去問 A 同事,他手上的任務進度,然後告訴 PM 。如果採用這樣的解法,PM 接下來就會得到啟發,開始頻繁的去追 RD 的進度,每天的工作負擔變重,形成了新的張力;而舒緩之道就是,降低追進度的頻率,過沒多久,進度又開始不明,張力-舒緩系統變成了擺盪的系統:

https://ithelp.ithome.com.tw/upload/images/20210921/20129624XC8A4ETCEK.png

從上圖來看,兩種張力無法同時的舒緩,同時追問進度,又不能問得太頻繁。這裡衍伸的問題是,當 PM 的張力舒緩了,但 RD 一定會不堪其擾,因為沒有 RD 喜歡每天被追著問:你的進度呢?

就這是典型的解決眼前問題,但忽略了「系統性問題」,讓張力四處的碰撞。當然你可以說,我們可以在中間抓一個平衡啊,但其實這是一種迴避處理複雜情境的推託之詞。所以針對這個情境,我們該做的是:

創造具有「透明化」的專案推進狀況特性的系統

我在另一個團隊中遇到的張力,來自 QA 部門。某次,QA 同事帶著煩惱來找我:「 B 同事交給我們驗証的程式,時常在簡單的正向流程就有 Bug ,導至我們雙方必須來來回回好幾次,影嚮產品的交付時間;我們也嘗試過在實作前先跟他開會,提供很詳細的驗証步驟給他,一來我們的工作量變大了,二來他覺得我們在找碴。現在情況雖然有好轉,但他產出很蠢的 Bug 機會還是很高。」
此時 QA 的張力舒緩系統如下:

https://ithelp.ithome.com.tw/upload/images/20210921/20129624A8Pd53ymZH.png

如同我上段所說,改善這個狀況,緊盯 B 同事的工作絕不是好主意。最好的方法:

創造「降低出錯率」的開發系統

每個團隊會遇到的狀況不一樣,所以張力-舒緩系統也不同。在團隊中常見的情況是,當系統不健康時,總會有某個成員會以增加工作量的方式,來讓系統內的張力得到舒緩。用人的抗壓性來解決系統問題,也太不人性。

我們最終想要得到的團隊系統,可以這樣描述:

一個高效的敏捷 Scrum 團隊,具透明化、高品質是這個系統的性質。

如果你要的「禪機」一直不來怎麼辦?這表示你的團隊系統處在一個穩定態下,系統中的張力是讓團隊成員舒服的,此時進行系統修改,不僅無效,而且容易引起反彈。團隊的最高優先任務,還是在於「產出」。如果產出都正常,成員也滿意於現狀,不要冒然的進行改革。張力總會累積,就耐心的等待張力需要釋放的時刻到來吧!


上一篇
[Day05] 團隊無雜事,只有混亂的訊息流
下一篇
[Day07] 團隊系統設計 - 規畫迷思
系列文
初階主管求生指南30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言